home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940211.txt < prev    next >
Internet Message Format  |  1994-11-13  |  40KB

  1. Date: Sat, 24 Sep 94 04:30:03 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #211
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Sat, 24 Sep 94       Volume 94 : Issue  211
  11.  
  12. Today's Topics:
  13.                  Actually, I *like* Brian's listserv
  14.                             enet anomalie
  15.                       gateway software? (4 msgs)
  16.                            Hubris (3 msgs)
  17.                 KA9Q NOS doesn't work with a PI board
  18.                              Mail failure
  19.                        Reading and how to stop
  20.                       TCP-Group Digest V94 #210
  21.                       Virtual machines (3 msgs)
  22.                          what is MAC (5 msgs)
  23.  
  24. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  25. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  26. Problems you can't solve otherwise to brian@ucsd.edu.
  27.  
  28. Archives of past issues of the TCP-Group Digest are available
  29. (by FTP only) from UCSD.Edu in directory "mailarchives".
  30.  
  31. We trust that readers are intelligent enough to realize that all text
  32. herein consists of personal comments and does not represent the official
  33. policies or positions of any party.  Your mileage may vary.  So there.
  34. ----------------------------------------------------------------------
  35.  
  36. Date: Fri, 23 Sep 94 10:55 EDT
  37. From: nelson@crynwr.com (Russell Nelson)
  38. Subject: Actually, I *like* Brian's listserv
  39. To: ssampson@sabea-oc.af.mil, listserv@UCSD.EDU, tcp-group@UCSD.EDU
  40.  
  41. delete tcp-group ssampson@sabea-oc.af.mil
  42.  
  43. ------------------------------
  44.  
  45. Date: Sat, 24 Sep 1994 04:18:25 -0700
  46. From: kd5lu@kd5lu.ampr.org (kd5lu)
  47. Subject: enet anomalie
  48. To: tcp-group@ucsd.edu
  49.  
  50. Scenario: Jnos box 10.g connected to windows pc via enet card.
  51. Problem : I can connect just fine to jnos from windows.  Problem is,
  52.           after I connect to another ax25 station (via the connect
  53.           command in the mb), each character I type gets sent out over
  54.           the ax25 interface.  The corresponding station does not know
  55.           what to do with all my single character madness.  This raises
  56.           a couple of questions I would appreciate some input on:
  57.  
  58.           1.  Upon inspecting the trace of the enet interface, I see each
  59.               character I enter on the windows/pc getting transmitted over
  60.               to my jnos box.  Is this normal ?
  61.    
  62.           2.  If the preceeding question is normal operation, how is
  63.               it controlled where each character will NOT be sent over
  64.               the ax25 interface until I hit return ?
  65.  
  66.           The windows software is Trumpet Winsock with a current GVC
  67.           packet driver for the enet board.  Any comments and/or 
  68.           questions will be greatly appreciated.  Tnx and 73.
  69.           Bill Abernathy kd5lu.ampr.org  -  abernat@metronet.com    
  70. ----------------------------------------------------------------------------
  71. Bill Abernathy kd5lu.ampr.org [44.28.0.119] abernath@netcom.com
  72. ---------------------------------------------------------------------------- 
  73.  
  74. ------------------------------
  75.  
  76. Date: Fri, 23 Sep 1994 08:09:31 -0400 (EDT)
  77. From: Brian Hartsfield <bh@eng.auburn.edu>
  78. Subject: gateway software?
  79. To: John Paul Morrison <jmorriso@bogomips.ee.ubc.ca>
  80.  
  81. On Thu, 22 Sep 1994, John Paul Morrison wrote:
  82.  
  83. > What software are people using on their gateways? I'm having terrible
  84. > luck with the stability of KA9Q, Jnos etc. Did you compile your own?
  85. > Do you have a huge patch file you keep around to apply to new versions
  86. > of NOS? I don't care what flavour you're using; if it's stable I wan't
  87. > to try what you're using.
  88. > I need a *stable* tcp/ip router and gateway (ip over ip encap) for
  89. > ethernet to 56kbps and 1200bps packet. Just tonight I was using rcp to
  90. > copy 15 megs of a directory tree over the 56kbps link; but then I
  91. > opened an ftp connection to a Sun; when I closed the ftp connection,
  92. > the JNOS router bit the dust (right in the middle of the rcp! arg!).
  93. > Rhetorical question: why can Suns, SGIs, Linux boxes etc. run for
  94. > *months* doing routing (and a million other things), and NOS up times
  95. > are measured in days at best?
  96.  
  97. Because nos is running on MS-DOS and a Sun, SGI, Lunix, etc are running 
  98. real operating systems.  nos tries to make dos do something it wasn't 
  99. designed for (multitasking, networking, etc.) and does a good job in the 
  100. attempt, but has trouble because of dos.   Your unix machines were 
  101. designed for doing multitasking networking and so they do it real well.
  102.  
  103. Your best bet for a stable tcp/ip is to run Jnos for Linux.
  104.  
  105. ------------------------------
  106.  
  107. Date: Fri, 23 Sep 1994 12:16:17 -0400
  108. From: "Louis A. Mamakos" <louie@alter.net>
  109. Subject: gateway software? 
  110. To: Brian Hartsfield <bh@eng.auburn.edu>
  111.  
  112. > On Thu, 22 Sep 1994, John Paul Morrison wrote:
  113. > > What software are people using on their gateways? I'm having terrible
  114. > > luck with the stability of KA9Q, Jnos etc. Did you compile your own?
  115. > > Do you have a huge patch file you keep around to apply to new versions
  116. > > of NOS? I don't care what flavour you're using; if it's stable I wan't
  117. > > to try what you're using.
  118. > > 
  119. > > I need a *stable* tcp/ip router and gateway (ip over ip encap) for
  120. > > ethernet to 56kbps and 1200bps packet. Just tonight I was using rcp to
  121. > > copy 15 megs of a directory tree over the 56kbps link; but then I
  122. > > opened an ftp connection to a Sun; when I closed the ftp connection,
  123. > > the JNOS router bit the dust (right in the middle of the rcp! arg!).
  124. > > Rhetorical question: why can Suns, SGIs, Linux boxes etc. run for
  125. > > *months* doing routing (and a million other things), and NOS up times
  126. > > are measured in days at best?
  127. > Because nos is running on MS-DOS and a Sun, SGI, Lunix, etc are running 
  128. > real operating systems.  nos tries to make dos do something it wasn't 
  129. > designed for (multitasking, networking, etc.) and does a good job in the 
  130. > attempt, but has trouble because of dos.   Your unix machines were 
  131. > designed for doing multitasking networking and so they do it real well.
  132. > Your best bet for a stable tcp/ip is to run Jnos for Linux.
  133.  
  134. Or you could try to run Just Plain Phil Karn NOS, and not feature-fied
  135. various which seem to be much less stable.  Of course, if you don't need
  136. to do any AX.25 nonsense, then a UN*X-like OS on the PC would give
  137. you many more options.
  138.  
  139. louie
  140. wa3ymh
  141.  
  142. ------------------------------
  143.  
  144. Date: Fri, 23 Sep 1994 14:05:23 -0400 (EDT)
  145. From: ron@chaos.eng.wayne.edu (Ron Atkinson)
  146. Subject: gateway software?
  147. To: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
  148.  
  149. > What software are people using on their gateways? I'm having terrible
  150. > luck with the stability of KA9Q, Jnos etc. Did you compile your own?
  151. > Do you have a huge patch file you keep around to apply to new versions
  152. > of NOS? I don't care what flavour you're using; if it's stable I wan't
  153. > to try what you're using.
  154.  
  155. Most people are running JNOS as a gateway, but reliability is very low
  156. when a large amount of data is passing through it, especially continuously
  157. at a high rate of speed.  Pretty odd that I've noticed the same thing
  158. as you have with UDP packets.  I can run telnets, ftp's, etc... through
  159. them, but many times when I run domain queries or try a talk program through
  160. a NOS system it dies.
  161.  
  162. If you really want to run JNOS and get some reliability try JNOS/Linux. I've
  163. had much better luck with this than any DOS version. It too can do goofy
  164. things though.  Is there a reason why you can't just run the AX.25 code in
  165. the kernel for Linux and run the IPIP daemon on that?  The IPIP daemon does
  166. work just fine, I've run it on 2 machines here and a couple other folks have
  167. run it too.  Do you have special hardware that no code exists for Linux yet
  168. that causes you to have to run a DOS machine?  Just curious...
  169.  
  170. If you do run JNOS/Linux you can set up a SLIP link via a pty to talk to the
  171. Linux machine and just route via that. Plus you can do your encap routing
  172. through that if you want to.   If you need to run DOS though I'd just stick
  173. with Phil's base code.  Also when running data at a high rate of speed through
  174. it turn off your trace on all your ports. Leaving a trace on will kill a NOS
  175. system pretty quickly.
  176.  
  177. -- 
  178.  
  179. Ron N8FOW
  180.  
  181. AMPRnet  : n8fow@n8fow.ampr.org
  182. Internet : ron@chaos.eng.wayne.edu
  183.            aa011@detroit.freenet.org
  184.  
  185. #include <std_disclaimer.h>
  186. /* all views and opinions expressed above are my own. */
  187.  
  188. ------------------------------
  189.  
  190. Date: Fri, 23 Sep 1994 12:01:06 -0800 (PDT)
  191. From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
  192. Subject: gateway software?
  193. To: ron@chaos.eng.wayne.edu (Ron Atkinson)
  194.  
  195. > > What software are people using on their gateways? I'm having terrible
  196. > > luck with the stability of KA9Q, Jnos etc. Did you compile your own?
  197. > > Do you have a huge patch file you keep around to apply to new versions
  198. > > of NOS? I don't care what flavour you're using; if it's stable I wan't
  199. > > to try what you're using.
  200. > Most people are running JNOS as a gateway, but reliability is very low
  201. > when a large amount of data is passing through it, especially continuously
  202. > at a high rate of speed.  Pretty odd that I've noticed the same thing
  203. > as you have with UDP packets.  I can run telnets, ftp's, etc... through
  204. > them, but many times when I run domain queries or try a talk program through
  205. > a NOS system it dies.
  206.  
  207. Apparently there's a patch for this, but I haven't seen it.
  208. > If you really want to run JNOS and get some reliability try JNOS/Linux. I've
  209. > had much better luck with this than any DOS version. It too can do goofy
  210. > things though.  Is there a reason why you can't just run the AX.25 code in
  211. > the kernel for Linux and run the IPIP daemon on that?  The IPIP daemon does
  212. > work just fine, I've run it on 2 machines here and a couple other folks have
  213. > run it too.  Do you have special hardware that no code exists for Linux yet
  214. > that causes you to have to run a DOS machine?  Just curious...
  215.  
  216. I already run Linux on one end of the 56k link (I don't need IPIP
  217. encap on that side); and I have few problems with tcp/ip routing.
  218. I've seen problems with ax.25 sockets in Linux, but I don't care,
  219. because the system we have is all tcp/ip.
  220.  
  221. Do you have IPIP running under Linux? Maybe I'll have to look at this
  222. again.  I compiled IPIP for Linux with some kludges, but I'm not sure
  223. if it was done properly. Not sure about the routes with IPIP either.
  224. Ideally, IPIP would go into the kernel, but I'm having trouble bending
  225. my mind around the various network kernel levels. It *looks* easy
  226. enough to do, but I'm not sure where to start. So do you have patches
  227. for IPIP and Linux?
  228.  
  229.  
  230. > If you do run JNOS/Linux you can set up a SLIP link via a pty to talk to the
  231. > Linux machine and just route via that. Plus you can do your encap routing
  232. > through that if you want to.   If you need to run DOS though I'd just stick
  233. > with Phil's base code.  Also when running data at a high rate of speed through
  234. > it turn off your trace on all your ports. Leaving a trace on will kill a NOS
  235. > system pretty quickly.
  236.  
  237. > -- 
  238. > Ron N8FOW
  239. > AMPRnet  : n8fow@n8fow.ampr.org
  240. > Internet : ron@chaos.eng.wayne.edu
  241. >            aa011@detroit.freenet.org
  242.  
  243. thanks
  244.  
  245. > #include <std_disclaimer.h>
  246. > /* all views and opinions expressed above are my own. */
  247.  
  248. ---------------------------------------------------------------------------
  249. BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  -- 
  250. jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org
  251. ---------------------------------------------------------------------------
  252.  
  253. ------------------------------
  254.  
  255. Date: Fri, 23 Sep 1994 06:38:05 -0500 (CDT)
  256. From: Gerald J Creager <gerry@cs.tamu.edu>
  257. Subject: Hubris
  258. To: ssampson@sabea-oc.af.mil (Steve Sampson)
  259.  
  260. Steve Sampson sez:
  261. > > Hubris
  262. > Isn't that what the fags at ucsd smear their butt with?
  263.  
  264. Comments like this are completely uncalled for on a public listserv response.
  265.  
  266.  
  267. > Well you should pat yourself on the back on the fine and wonderful
  268. > list server you "wrote".  I suspect it's probably the only thing you
  269. > ever finished...
  270.  
  271. Steve, if you're dissatisfied with the list, the author, or the folks who are
  272. on the list, why don't you follow your own advice and just unsubscribe?  Or,
  273. would you prefer someone do it for you?
  274.  
  275. Gerry
  276.  
  277. ------------------------------
  278.  
  279. Date: Fri, 23 Sep 1994 12:54:08 +0200 (BST)
  280. From: iialan@iifeak.swan.ac.uk (Alan Cox)
  281. Subject: Hubris
  282. To: ssampson@sabea-oc.af.mil (Steve Sampson)
  283.  
  284. > > Hubris
  285. > Isn't that what the fags at ucsd smear their butt with?
  286. > Well you should pat yourself on the back on the fine and wonderful
  287. > list server you "wrote".  I suspect it's probably the only thing you
  288. > ever finished...
  289.  
  290. I can only assume these are faking postings. Just in case I've taken the
  291. trouble to forward them to USAF with a request they are looked into
  292.  
  293. Alan
  294.  
  295. ------------------------------
  296.  
  297. Date: Fri, 23 Sep 1994 18:14:44 +0100
  298. From: "Brian A. Lantz" <brian@lantz.cftnet.com>
  299. Subject: Hubris
  300. To: Steve Sampson <ssampson@sabea-oc.af.mil>
  301.  
  302. On Fri, 23 Sep 1994, Steve Sampson wrote:
  303.  
  304. > > Hubris
  305. > Isn't that what the fags at ucsd smear their butt with?
  306. > Well you should pat yourself on the back on the fine and wonderful
  307. > list server you "wrote".  I suspect it's probably the only thing you
  308. > ever finished...
  309. > -- 
  310. > Steve
  311.  
  312.  
  313. I have seen unacceptable and unnecessary messages on this list before. I 
  314. have seen people flamed for helping and flamed for being just born. I 
  315. have seen people flame others because they  didn't GIVE their time and 
  316. energy faster and in the way that the flamer thought it should be done.
  317.  
  318. But you know, this message of sincere ingratitude only goes to show that 
  319. when you think you have seen it all, you haven't!
  320.  
  321. Steve, Buddy, If you don't like Brian and his tcp-group list, DON'T USE 
  322. IT! It's HIS party and he'll cry if he wants to. You, as is with the rest 
  323. of us, have little or no say.
  324.  
  325. DON'T show your south side while facing north and lead Brian to believe 
  326. that the members of this group support such uncalled-for ravings.
  327.  
  328.  
  329. BRIAN:
  330.  
  331. May of us in the Amateur Community very much appreciate the MANY things 
  332. you have FINISHED that have helped make Amateur Radio TCP what it is 
  333. today. Don't let random, ill conceived flames sway you.
  334.  
  335.  
  336. -----------------------------------------------------------
  337. Brian A. Lantz/KO4KS                 brian@lantz.cftnet.com
  338.  
  339. REAL PORTION of Microsoft Windows code:
  340.     while (memory_available)    {
  341.         eat_major_portion_of_memory (no_real_reason);
  342.         if (feel_like_it)
  343.             make_user_THINK (this_is_an_OS);
  344.         gates_bank_balance++;
  345.     }
  346.  
  347. ------------------------------
  348.  
  349. Date: Fri, 23 Sep 1994 20:11:25 -0700 (PDT)
  350. From: rosenaue@mprgate.mpr.ca (Dennis Rosenauer)
  351. Subject: KA9Q NOS doesn't work with a PI board
  352. To: tcp-group@UCSD.EDU
  353.  
  354. I have been attempting to get the KA9Q NOS running with a PI board.  I have
  355. found that JNOS and others (PA0GRI 1229M etc.) crash with high volumes
  356. of IP (UDP) traffic.  It was suggested by others on this group that
  357. Phil's KA9Q NOS was better in this regard.
  358.  
  359. I obtained the sources from ftp.ucsd.edu and after a little messing around
  360. with RCS (I set it all up on one of my UNIX boxes to unbundle it properly)
  361. and adding a few patches from WA7IPX it compiled and seemed to run.
  362.  
  363. However, I cannot get the PI board interface to work at all.  The version
  364. of NOS I got is "930622 (KA9Q)".  Does anyone have any patches to make
  365. the PI board work?  The ethernet interface via a packet driver works fine.
  366. I have not tried using the PI board packet driver with KA9Q recently but
  367. it did not seem to work when I tested it earlier this year.
  368.  
  369. Suggestions?
  370.  
  371. Thanks, Dennis.
  372.  
  373. -- 
  374. Dennis Rosenauer VE7BPE                  rosenaue@mpr.ca
  375. MPR Teltech Ltd.
  376. Wireless Transmission Products           "For every vision there is an
  377. Burnaby, B. C.                            equal and opposite revision"
  378.  
  379. ------------------------------
  380.  
  381. Date: Fri, 23 Sep 94 12:15:00 edt
  382. From: Adminstrator <POSTMASTER@gppgpost.daytonoh.NCR.COM>
  383. Subject: Mail failure
  384. To: dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.NCR.COM
  385.  
  386.                                                                                
  387. User mail received addressed to the following unknown addresses:
  388.   GPPGDAYTON/GPPGPOST/lshannon
  389.                                                                                
  390. ------------------------------------------------------------------------------ 
  391. Return-Path: <dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.ncr.com>
  392. Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
  393.     <2E82FF0D@gppgpost.daytonoh.ncr.com>; Fri, 23 Sep 94 12:15:09 edt
  394. Received: by prowler.daytonoh.ncr.com; 23 Sep 94 11:46:14 EDT
  395. Received: by dayhub.DaytonOH.NCR.COM; 23 Sep 94 11:46:05 EDT
  396. Received: by 3445a.DaytonOH.NCR.COM; 23 Sep 94 11:46:34 EDT id AA780335469
  397.     Fri, 23 Sep 94 11:51:09 EST
  398. Date: Fri, 23 Sep 94 11:51:09 EST
  399. From: TCP-Group@ucsd.edu
  400. Message-Id: <9408237803.AA780335469@WPDSMTP.DaytonOH.NCR.COM>
  401. To: tcp-group-digest@ucsd.edu
  402. Subject: TCP-Group Digest V94 #210
  403.                                                                               
  404.  
  405. Received: by ccmail from 3445a.DaytonOH.NCR.COM
  406. >From ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM
  407. X-Envelope-From: ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM
  408. Received: by 3445a.DaytonOH.NCR.COM; 23 Sep 94 11:41:55 EDT
  409. Received: by dayhub.DaytonOH.NCR.COM; 23 Sep 94 11:41:09 EDT
  410. Received: from ncrgw1 by ncrhub1.NCR.COM id ad10307; 23 Sep 94 11:39 EDT
  411. Received: by ncrgw1.NCR.COM; 23 Sep 94 11:36:29 EDT
  412.     sendmail 8.6.9/UCSD-2.2-sun
  413.     Fri, 23 Sep 1994 04:30:11 -0700 for tcp-digest-list
  414. Received: by ucsd.edu; id EAA26150
  415.     sendmail 8.6.9/UCSD-2.2-sun
  416.     Fri, 23 Sep 1994 04:30:08 -0700 for tcp-group-ddist
  417. Message-Id: <199409231130.EAA26150@ucsd.edu>
  418. Date: Fri, 23 Sep 94 04:30:03 PDT
  419. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  420. Errors-To: TCP-Group-Errors@UCSD.EDU
  421. Reply-To: TCP-Group@ucsd.edu
  422. Precedence: Bulk
  423. Subject: TCP-Group Digest V94 #210
  424. To: tcp-group-digest@ucsd.edu
  425.  
  426. TCP-Group Digest            Fri, 23 Sep 94       Volume 94 : Issue  210
  427.  
  428. Today's Topics:
  429.                           gateway software?
  430.                     How to Join or Leave (2 msgs)
  431.                                 Hubris
  432.                              Mail failure
  433.                        TCP retry time problem?
  434.                    wn940921 : where can I find it?
  435.  
  436. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  437. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  438. Problems you can't solve otherwise to brian@ucsd.edu.
  439.  
  440. Archives of past issues of the TCP-Group Digest are available
  441. (by FTP only) from UCSD.Edu in directory "mailarchives".
  442.  
  443. We trust that readers are intelligent enough to realize that all text
  444. herein consists of personal comments and does not represent the official
  445. policies or positions of any party.  Your mileage may vary.  So there.
  446. ----------------------------------------------------------------------
  447.  
  448. Date: Thu, 22 Sep 1994 21:56:54 -0800 (PDT)
  449. From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
  450. Subject: gateway software?
  451. To: gateways@mpg.phys.hawaii.edu, tcp-group@ucsd.edu
  452.  
  453. What software are people using on their gateways? I'm having terrible
  454. luck with the stability of KA9Q, Jnos etc. Did you compile your own?
  455. Do you have a huge patch file you keep around to apply to new versions
  456. of NOS? I don't care what flavour you're using; if it's stable I wan't
  457. to try what you're using.
  458.  
  459. I need a *stable* tcp/ip router and gateway (ip over ip encap) for
  460. ethernet to 56kbps and 1200bps packet. Just tonight I was using rcp to
  461. copy 15 megs of a directory tree over the 56kbps link; but then I
  462. opened an ftp connection to a Sun; when I closed the ftp connection,
  463. the JNOS router bit the dust (right in the middle of the rcp! arg!).
  464. Rhetorical question: why can Suns, SGIs, Linux boxes etc. run for
  465. *months* doing routing (and a million other things), and NOS up times
  466. are measured in days at best?
  467.  
  468.  
  469. thanks
  470.  
  471.  
  472. ---------------------------------------------------------------------------
  473. BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  -- 
  474. jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org
  475. ---------------------------------------------------------------------------
  476.  
  477. ------------------------------
  478.  
  479. Date: Thu, 22 Sep 1994 15:33:57 -0500 (CDT)
  480. From: ssampson@sabea-oc.af.mil (Steve Sampson)
  481. Subject: How to Join or Leave
  482. To: tcp-group@ucsd.edu
  483.  
  484. One of the most irritating problems of a listserver is that people don't
  485. remember how they got in, or the instructions for getting out.  For this
  486. particular group, you would probably check the masthead of the tcp-group
  487. digest. Of course that won't help, because the masthead is wrong - always
  488. has been.  The simple fact is that most listservers use the user name of
  489.  
  490.  listserv
  491.  
  492. Those that don't are non-standard, and should probably be avoided if you
  493. have a poor memory.
  494.  
  495. The tcp-group is archived on the ucsd.edu machine.  So the full address is
  496.  
  497.  listserv@ucsd.edu
  498.  
  499. Now here's the fun part. Just send the word
  500.  
  501.  help
  502.  
  503. In the message.  Don't include your damned 12 line signature block with
  504. stupid graphics either.
  505.  
  506. If a member see's that another member is having trouple they can also
  507. unsubscribe them.
  508.  
  509.  delete-all joe@blow.edu
  510.  
  511. -- 
  512. Steve
  513.  
  514. ------------------------------
  515.  
  516. Date: Thu, 22 Sep 1994 20:21:22 -0700
  517. From: brian@nothing.ucsd.edu (Brian Kantor)
  518. Subject: How to Join or Leave
  519. To: tcp-group@ucsd.edu, ssampson@sabea-oc.af.mil
  520.  
  521. In article <9409222033.AA08892@sabea-oc.af.mil> you write:
  522. >particular group, you would probably check the masthead of the tcp-group
  523. >digest. Of course that won't help, because the masthead is wrong - always
  524. >has been.
  525.  
  526. Steve is so sure of himself.  Unfortunately, he's wrong.  The masthead
  527. of the tcp-digest clearly states to send mail to tcp-group-request@ucsd.edu,
  528. and by golly, that works for me!
  529.  
  530. But then, Steve knows better than I do.  Hey, I just wrote the software,
  531. the masthead, and run the system.  
  532.  
  533. So do it his way.  Or as the instructions say.  Your choice.
  534.  
  535. Gosh, I wish >I< were young enough to know everything.  Hubris, I think
  536. they call it.
  537.  - Brian
  538.  
  539. ------------------------------
  540.  
  541. Date: Fri, 23 Sep 1994 04:32:32 -0500 (CDT)
  542. From: ssampson@sabea-oc.af.mil (Steve Sampson)
  543. Subject: Hubris
  544. To: tcp-group@ucsd.edu
  545.  
  546. > Hubris
  547.  
  548. Isn't that what the fags at ucsd smear their butt with?
  549.  
  550. Well you should pat yourself on the back on the fine and wonderful
  551. list server you "wrote".  I suspect it's probably the only thing you
  552. ever finished...
  553.  
  554. -- 
  555. Steve
  556.  
  557. ------------------------------
  558.  
  559. Date: Thu, 22 Sep 94 13:47:00 edt
  560. From: Adminstrator <POSTMASTER@gppgpost.daytonoh.NCR.COM>
  561. Subject: Mail failure
  562. To: dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.NCR.COM
  563.  
  564.                                                                              
  565.  
  566. User mail received addressed to the following unknown addresses:
  567.   GPPGDAYTON/GPPGPOST/lshannon
  568.                                                                              
  569.  
  570. ------------------------------------------------------------------------------ 
  571.  
  572. Return-Path: <dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.ncr.com>
  573. Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
  574.     <2E81C331@gppgpost.daytonoh.ncr.com>; Thu, 22 Sep 94 13:47:29 edt
  575. Received: by prowler.daytonoh.ncr.com; 22 Sep 94 13:30:34 EDT
  576. Received: by dayhub.DaytonOH.NCR.COM; 22 Sep 94 13:30:23 EDT
  577. Received: by 3445a.DaytonOH.NCR.COM; 22 Sep 94 13:30:46 EDT id AA780255289
  578.     Thu, 22 Sep 94 13:34:49 EST
  579. Date: Thu, 22 Sep 94 13:34:49 EST
  580. From: TCP-Group@ucsd.edu
  581. Message-Id: <9408227802.AA780255289@WPDSMTP.DaytonOH.NCR.COM>
  582. To: tcp-group-digest@ucsd.edu
  583. Subject: TCP-Group Digest V94 #209
  584.                                                                               
  585.  
  586. Received: by ccmail from 3445a.DaytonOH.NCR.COM
  587. >From ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM
  588. X-Envelope-From: ncrhub1!ucsd.edu!owner-tcp-digest@dayhub.DaytonOH.NCR.COM
  589. Received: by 3445a.DaytonOH.NCR.COM; 22 Sep 94 13:27:45 EDT
  590. Received: by dayhub.DaytonOH.NCR.COM; 22 Sep 94 13:27:01 EDT
  591. Received: from ncrgw1 by ncrhub1.NCR.COM id as24192; 22 Sep 94 12:23 EDT
  592. Received: by ncrgw1.NCR.COM; 22 Sep 94 10:42:15 EDT
  593.     sendmail 8.6.9/UCSD-2.2-sun
  594.     Thu, 22 Sep 1994 04:30:09 -0700 for tcp-digest-list
  595. Received: by ucsd.edu; id EAA26135
  596.     sendmail 8.6.9/UCSD-2.2-sun
  597.     Thu, 22 Sep 1994 04:30:07 -0700 for tcp-group-ddist
  598. Message-Id: <199409221130.EAA26135@ucsd.edu>
  599. Date: Thu, 22 Sep 94 04:30:06 PDT
  600. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  601. Errors-To: TCP-Group-Errors@UCSD.EDU
  602. Reply-To: TCP-Group@ucsd.edu
  603. Precedence: Bulk
  604. Subject: TCP-Group Digest V94 #209
  605. To: tcp-group-digest@ucsd.edu
  606.  
  607. TCP-Group Digest            Thu, 22 Sep 94       Volume 94 : Issue  209
  608.  
  609. Today's Topics:
  610.                              Mail failure
  611.                                UNSCRIBE
  612.                       wn940921 memory and things
  613.  
  614. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  615. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  616. Problems you can't solve otherwise to brian@ucsd.edu.
  617.  
  618. Archives of past issues of the TCP-Group Digest are available
  619. (by FTP only) from UCSD.Edu in directory "mailarchives".
  620.  
  621. We trust that readers are intelligent enough to realize that all text
  622. herein consists of personal comments and does not represent the official
  623. policies or positions of any party.  Your mileage may vary.  So there.
  624. ----------------------------------------------------------------------
  625.  
  626. Date: Wed, 21 Sep 94 13:34:00 edt
  627. From: Adminstrator <POSTMASTER@gppgpost.daytonoh.NCR.COM>
  628. Subject: Mail failure
  629. To: dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.NCR.COM
  630.  
  631.                                                                              
  632.  
  633. User mail received addressed to the following unknown addresses:
  634.   GPPGDAYTON/GPPGPOST/lshannon
  635.                                                                              
  636.  
  637. ------------------------------------------------------------------------------ 
  638.  
  639.  
  640. Return-Path: <dayhub!3445a!ucsd.edu!TCP-Group@prowler.daytonoh.ncr.com>
  641. Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
  642.     <2E806E8E@gppgpost.daytonoh.ncr.com>; Wed, 21 Sep 94 13:34:06 edt
  643. Received: by prowler.daytonoh.ncr.com; 21 Sep 94 13:30:09 EDT
  644. Received: by dayhub.DaytonOH.NCR.COM; 21 Sep 94 13:29:48 EDT
  645. Received: by 3445a.DaytonOH.NCR.COM; 21 Sep 94 13:26:24 EDT id AA780168631
  646.     Wed, 21 Sep 94 13:30:31 EST
  647. Date: Wed, 21 Sep 94 13:30:31 EST
  648. From: TCP-Group@ucsd.edu
  649. Message-Id: <9408217801.AA780168631@WPDSMTP.DaytonOH.NCR.COM>
  650. To: tcp-group-digest@ucsd.edu
  651. Subject: TCP-Group Digest V94 #208
  652.                                                                               
  653. Large message has been converted into an attachment.
  654.  
  655. ------------------------------
  656.  
  657. Date: Wed, 21 Sep 1994 21:11:15 -0400 (EDT)
  658. From: Admin <uunet!k4ngc!root>
  659. Subject: UNSCRIBE
  660. To: uunet!aquin!men2a!uunet.uu.net!ucsd!tcp-group
  661.  
  662. UNSCRIBE
  663.  
  664. ------------------------------
  665.  
  666. Date: Wed, 21 Sep 94 14:54:51 EST
  667. From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
  668. Subject: wn940921 memory and things
  669. To: TCP-GROUP <TCP-GROUP@ucsd.edu>, wnos-group <WNOS-L@edugraf.ufsc.br>
  670.  
  671. Just to confirm unless informed otherwise. the memory problem
  672. on this version of wnos is cleared.
  673. and the latest uploaded .exe's do contain netrom.
  674. however I compiled both in 286 mode on the compiler.
  675. Barry.
  676.  
  677. ------------------------------
  678.  
  679. End of TCP-Group Digest V94 #209
  680. ******************************
  681.  
  682. ------------------------------
  683.  
  684. Date: Thu, 22 Sep 94 07:27:00 -0000
  685. From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow)
  686. Subject: TCP retry time problem?
  687. To: nos-bbs@hydra.carleton.ca
  688.  
  689. [Replying originally to a post addressed to the nos-bbs@hydra.carleton.ca
  690. list]
  691.  
  692. On 94 Sep 20 at 10:52, Dr. Gareth D. Blower <Gareth@oxfdpara.demon.co.uk>
  693. wrote:
  694.  
  695.  DGDB> rto = backoff(tcb) * (4 * tcb->mdev + tcb->srtt);
  696.  
  697.  DGDB> Where does that factor of 4 get plucked from? It means 
  698.  DGDB> that when we calculate the retry time, we give the mean 
  699.  DGDB> deviation of the RTT 4 times the weight of the RTT itself. 
  700. * * *
  701.  DGDB> If we do a PING to a particular station, we will see 
  702.  DGDB> quite a small mean deviation, but that's because we send 
  703.  DGDB> one packet at time. When we are doing an FTP, we may send, 
  704.  DGDB> all in one go, any number of packets, depending on the
  705.  DGDB> negotiated window size. If we send one packet, and then 
  706.  DGDB> two contiguous packets, and then three contiguous packets, 
  707.  DGDB> the RTT will vary. For one packet, it will be 
  708.  DGDB> approximately RTT. If two packets are sent contiguously, 
  709.  DGDB> the RTT for the first packet will be approximately 1.5 
  710.  DGDB> RTT. If three packets are sent contiguously, the RTT for 
  711.  DGDB> the first packet will be approximately 2 RTT
  712.  
  713. What you say has quite a lot of validity, but I think the reasoning was most
  714. likely to concoct a quick and dirty mechanism to prevent the retry timer from
  715. expiring on one packet while others are still being sent.  This is an inherent
  716. problem on a half-duplex channel, since the RTT can only be measured on a
  717. packet-by-packet basis.  It might be reasonable to extend Karn's Algorithm to
  718. say that we will only use an RTT measurement taken from an acknowledgement of
  719. the last transmitted frame.  If we did this, then we would never get any RTT
  720. measurements unless we drop into stop-and-wait mode somehow, either through
  721. the
  722. use of the congestion window or some other cause.  You might ask Phil Karn
  723. about this directly, although I believe that he has traditionally expressed
  724. objection to any linear backoff implementation as opposed to exponential
  725. backoff.
  726.  
  727. -- Mike
  728.  
  729.  
  730. ------------------------------
  731.  
  732. Date: Fri, 23 Sep 94 11:19:52 utc
  733. From: iw1cfl@ik1qld-10.ampr.org
  734. Subject: wn940921 : where can I find it?
  735. To: tcp-group@ucsd.edu
  736.  
  737. Hello all, 
  738. where can I find wn940921 sources other than ucsd.edu?
  739.  
  740. The problemi is that here the connectionf with ftp.ucsd.edu is slow,
  741. so if I can connect another host maybe i can download it easily.
  742.  
  743. Best 73
  744.  
  745. Mike
  746.  
  747. ------------------------------
  748.  
  749. End of TCP-Group Digest V94 #210
  750. ******************************
  751.  
  752. ------------------------------
  753.  
  754. Date: Fri, 23 Sep 1994 13:22:24 -0600 (MDT)
  755. From: Klarsen <klarsen@kazak.NMSU.Edu>
  756. Subject: Reading and how to stop
  757. To: TCP digest <tcp-group@ucsd.edu>
  758.  
  759.     I was amuased at myself. I read Steve's thing about getting 
  760. information on this server and said yes the masthead has been wrong for 
  761. years! Then I saw Brian's note and re-looked at the masthead.
  762.  
  763.     There it IS! In clear easy to read form, how to send this message 
  764. and how to send things to the server. I tried it and it works. But I 
  765. think one added thing might help end so many messages to "cancel my 
  766. subscription". As Steve said you can send a 1 liner one word that will 
  767. get you lots of information. Just use help.
  768.  
  769.     But to get this across might be hard. The person wanting help 
  770. needs to know that the 'help' must be in the message, not the title and 
  771. with some servers it needs to not be the first line.
  772.  
  773.     I wonder how hard it would be to have the server answer a address 
  774. like help@ucsd.edu or help_request@ucsd.edu send the help file? Then you 
  775. could put that in the masthead as " for help use help@ucsd.edu" and the 
  776. user winds up with your excellent help file.
  777.  
  778.     Just another hair-brain idea...
  779.  
  780. -karl
  781.  
  782. ------------------------------
  783.  
  784. Date: Fri, 23 Sep 1994 18:21:00 PDT
  785. From: "Jeffrey D. Angus" <jangus@skyld.grendel.com>
  786. Subject: TCP-Group Digest V94 #210
  787. To: TCP-Group@UCSD.EDU
  788.  
  789. On Fri, 23 Sep 94 04:30:03 PDT, "Advanced Amateur Radio Networking Group" <tcp-group@UCSD.EDU> wrote:
  790. >                                 Hubris
  791. > Date: Fri, 23 Sep 1994 04:32:32 -0500 (CDT)
  792. > From: ssampson@sabea-oc.af.mil (Steve Sampson)
  793. > Subject: Hubris
  794. > To: tcp-group@ucsd.edu
  795. > > Hubris
  796.  
  797. [ rest deleted.... ]
  798.  
  799. Congratulations Steve. I've managed to maintain the title of net.asshole for
  800. quite sometime, but this time you've beat me fair and square.
  801.  
  802. I humbly surrender my title.
  803.  
  804. 73 es GE from the vanquished
  805.  
  806. -- 
  807.  Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NOAM | "You have a flair for adding
  808. Internet: jangus@skyld.grendel.com        |  a fanciful dimension to any
  809.  US Mail: PO Box 4425 Carson, CA 90749    |  story."
  810.    Phone: 1 (310) 324-6080                |           Peking Noodle Co.
  811.  
  812. Hate "Green Card Lottery"? Want to help curb ignorant crossposting on Usenet?
  813. E-mail ckeroack@hamp.hampshire.edu for more information, or read news.groups.
  814.  
  815. ------------------------------
  816.  
  817. Date: Fri, 23 Sep 1994 09:50:22 MDT
  818. From: nq0i@dablik.radiophysics.com
  819. Subject: Virtual machines
  820. To: tcp-group@ucsd.edu
  821.  
  822. Working on the assumption that there are no stupid questions, I 
  823. proceed with the following:
  824.  
  825. I think that most of us agree that a good configuration for radio 
  826. access is to have a DOS machine running NOS actually attached to the 
  827. rig, acting as an IP switch to a box running *NIX or Windows or 
  828. what-have-you on which the applications run.
  829.  
  830. Now, suppose that this second machine is running Windows. Is there 
  831. some way in which the DOS switch running NOS cannot be replaced by a 
  832. virtual DOS machine running NOS within the Windows session?
  833.  
  834. Obviously (I think) if one has enough COM ports, one could route the
  835. IP from a Windows application attached to (say) Winsock out one
  836. port, into another post to which is attached a Windows DOS box running
  837. NOS, which can then ship the final radio-ready IP out a third port.
  838. But is there not some way to get rid of those first two ports through 
  839. some virtualising mechanism so that the IP from Winsock (or whatever) 
  840. goes into the NOS session without physically having to traverse 
  841. wires?
  842.  
  843. I apologise if this makes the cognoscenti shake their heads in 
  844. wonderment at my simplicity....
  845.  
  846. Doc
  847.  
  848.  
  849. -------------------------------------------------------
  850. Doc Evans NQ0I / G4AMJ : devans@orion.colorado.edu
  851.                          al019@freenet.hsc.colorado.edu
  852. -------------------------------------------------------
  853.  
  854. ------------------------------
  855.  
  856. Date: Fri, 23 Sep 1994 17:41:59 +0200 (BST)
  857. From: iialan@iifeak.swan.ac.uk (Alan Cox)
  858. Subject: Virtual machines
  859. To: al019@freenet.hsc.colorado.edu
  860.  
  861. > I think that most of us agree that a good configuration for radio 
  862. > access is to have a DOS machine running NOS actually attached to the 
  863. > rig, acting as an IP switch to a box running *NIX or Windows or 
  864. > what-have-you on which the applications run.
  865.  
  866. Running JNOS under Linux is more than as good. Once the AX.25 for Linux
  867. and *BSD is finished and done the DOS boxes can go into the bits pile
  868.  
  869. > IP from a Windows application attached to (say) Winsock out one
  870. > port, into another post to which is attached a Windows DOS box running
  871. > NOS, which can then ship the final radio-ready IP out a third port.
  872. > But is there not some way to get rid of those first two ports through 
  873. > some virtualising mechanism so that the IP from Winsock (or whatever) 
  874. > goes into the NOS session without physically having to traverse 
  875.  
  876. In theory it is doable (I've seen that kind of hackery work) but the right
  877. way of doing it is to get a winsock or DOS tcp stack that can be taught
  878. do to IP over AX.25 UI frames (which isn't a complex protocol problem).
  879. Hacking WATTCP to do this took me an afternoon but then I found wattcp's
  880. tcp timers were just far too simple to cope with the amateur radio network.
  881.  
  882. Alan
  883.  
  884. ------------------------------
  885.  
  886. Date: Sat, 24 Sep 94 00:28:35 UTC
  887. From: ve3dte@ve3dte.ampr.org
  888. Subject: Virtual machines
  889. To: al019@freenet.hsc.colorado.edu
  890.  
  891. If you want to run Winsock apps over radio, and you don't need
  892. multiple radio ports, I've found that K8LT's KISS packet driver
  893. works quite well with Trumpet Winsock.
  894.  
  895. The timers are acceptable, with an initial RTT of 5 seconds and
  896. exponential backoff.  The DNS code is a bit of a problem, since
  897. it re-tries domain lookups at fixed 5 second intervals -- so
  898. it's best to have a DNS close by :-)   It even works fairly
  899. well at 1200bps.
  900.  
  901. This approach should also work with the Ottawa PI card, since
  902. there is a packet driver for it in the Crynwr collection.
  903.  
  904. The KISS driver is available at ftp.ucsd.edu, in /hamradio/packet
  905. /tcpip/incoming/ethrax25.zip  Source is included.
  906.  
  907. 73, Mark.
  908.  
  909. ve3dte@ve3dte.ampr.org
  910. markfrey@hookup.net
  911.  
  912. ------------------------------
  913.  
  914. Date: Fri, 23 Sep 94 14:34:12 EST
  915. From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
  916. Subject: what is MAC
  917. To: TCP-GROUP <TCP-GROUP@ucsd.edu>
  918.  
  919. Hi all.
  920. I have a simple Question, What is MAC
  921. I know its hardware address remap to Ip address.
  922. But What does M.A C mean
  923. Thanks. Barry
  924.  
  925. ------------------------------
  926.  
  927. Date: Fri, 23 Sep 94 10:27:47      
  928. From: kz1f@RELAY.HDN.LEGENT.COM
  929. Subject: what is MAC
  930. To: "BARRY TITMARSH" <BTITMARS%ESOC.BITNET@vm.gmd.de>, tcp-group@ucsd.edu
  931.  
  932. Media Access Control (its an NDIS term) 
  933. NDIS has 3 components, 
  934. 1) MAC - this is the hardware drivers, written to a common interface spec 
  935. (to interface with protocol stack).
  936. 2) Protocol stack, this is the logic of whats going on, irrespective of 
  937. hardware.
  938. 3) Protocol Manager, this piece couples a protocol stack with whatever 
  939. MAC(s) are available. This is generally done thru a "bind" process.
  940.  
  941. You may want to get ahold of the NDIS 3.0 spec from either 3com or uSoft.
  942.  
  943.  
  944.  
  945. -Walt
  946.  
  947. ------------------------------
  948.  
  949. Date: Fri, 23 Sep 94 10:56 EDT
  950. From: nelson@crynwr.com (Russell Nelson)
  951. Subject: what is MAC
  952. To: BTITMARS%ESOC.BITNET@vm.gmd.de
  953.  
  954.    Date:         Fri, 23 Sep 94 14:34:12 EST
  955.    From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
  956.  
  957.    Hi all.
  958.    I have a simple Question, What is MAC
  959.    I know its hardware address remap to Ip address.
  960.    But What does M.A C mean
  961.  
  962. Media Access Controller.
  963.  
  964. ------------------------------
  965.  
  966. Date: Fri, 23 Sep 1994 12:39:26 -0400
  967. From: "Louis A. Mamakos" <louie@alter.net>
  968. Subject: what is MAC 
  969. To: kz1f@RELAY.HDN.LEGENT.COM
  970.  
  971. > Media Access Control (its an NDIS term) 
  972.  
  973. Uh, I'm pretty sure that MAC predates NDIS by quite a bit.  
  974.  
  975. I believe the term was probably first used in the IEEE 802 specs; I
  976. just checked my DEC/Intel/Xerox Ethernet Version 1.0 spec (Sept 30,
  977. 1980), and they don't actually use that term.  I
  978.  
  979. louie
  980.  
  981. ------------------------------
  982.  
  983. Date: Fri, 23 Sep 1994 17:04:32 +0000 (GMT)
  984. From: Paul L Taylor <PAUL%RADARC@email.meto.govt.uk>
  985. Subject: what is MAC
  986. To: TCP-GROUP@UCSD.EDU
  987.  
  988. Hello Barry,
  989.  
  990.    Its Medium Access Control, I think its reasonably self-explanatory but it
  991. is covered well in the usual reference material Like Tanenbaum's Computer 
  992. Networks,or Black's various tomes,or even IEEE 802 standards.But here is a
  993. little discourse on MAC :-)
  994.  
  995.   In the IEEE 802 committee's reference tomes they split the data link layer
  996. (OSI-RM ) into 2 sub-layers the Medium Access Control and the Logical Link 
  997. Control.
  998.    Where for instance 802.3 (ethernet thick or thin) defines CSMA/CD Carrier 
  999. Sense Multiple Access/Collision Detect method of MAC. The token bus method of 
  1000. MAC is the 802.4 standard,and the token ring method is 802.5 standard.
  1001. 802.2 is the Logical Link Control standard.
  1002.  
  1003. MAC itself is split into 6 sub-layers: Transmit Data Encapsulation,
  1004. Transmit Media Access Management,Receive Data Decapsulation,Receive Media 
  1005. Access Management,Data Encoding or Decoding and Channel Access.
  1006.  
  1007. Further study of the above references or any good Data Networking reference
  1008. should help you further.
  1009.   
  1010. 73 Paul
  1011.   -----------------------------------------------------------------------------
  1012. Telephone : +44 1344 855876 (1000-1900 GMT), +44 1494 526538 (2030-0000)
  1013. Fax       : +44 1344 855878
  1014. Full Name : Paul L Taylor 
  1015. Snail Mail: ATD Systems Analyst/Designer,The Met Office,Experimental Site,
  1016.             Beaufort Park,Easthamsted,Wokingham,Berks..RG11 3DN,UK
  1017. InterNet  : ptaylor@EMAIL.meto.govt.uk (please use THIS address NOT any other
  1018.                                         internally appended address)
  1019. JaNet     : ptaylor@uk.govt.met-office.email
  1020. AmprNet   : g1plt@g1plt.ampr.org  UK AmprNet Co-ordinator.
  1021. NTSbbs    : G1PLT@GB7MHD.#22.GBR.EU
  1022.     
  1023.  
  1024. ------------------------------
  1025.  
  1026. Date: Fri, 23 Sep 1994 10:16:37 -0500
  1027. From: tom@ping.ping.com (Tom Robertson)
  1028. To: TCP-GROUP@UCSD.EDU
  1029.  
  1030. unsubscribe
  1031.  
  1032. ------------------------------
  1033.  
  1034. End of TCP-Group Digest V94 #211
  1035. ******************************
  1036.